Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Nov 17, 2025

The client fails TLS verification when kubeconfig specifies a tls-server-name different from the server URL hostname. This is common with Teleport-generated configs where the certificate CN/SAN doesn't match the proxy IP.

Changes

  • KubeConfig: Added getTlsServerName() to read tls-server-name from cluster config
  • ApiClient: Added tlsServerName field and custom HostnameVerifier that delegates to OkHostnameVerifier.INSTANCE.verify(tlsServerName, session) instead of verifying against URL hostname
  • ClientBuilder: Wired tls-server-name from KubeConfig through to ApiClient

Example

clusters:
- cluster:
    server: https://192.168.1.1:6443
    tls-server-name: my-cluster.example.com  # Certificate has this CN/SAN
    certificate-authority-data: ...

The client now verifies the certificate against my-cluster.example.com instead of 192.168.1.1, allowing successful TLS handshake with mismatched hostnames.

Resolves issue where workaround required insecure-skip-tls-verify: true.

Original prompt

This section details on the original issue you should resolve

<issue_title>TLSServerName is not taken into account</issue_title>
<issue_description>Describe the bug

When using a kubeconfig which defines a tls-server-name field different from the server field, the client fails to validate the cluster certificate.

As a workaround, setting insecure-skip-tls-verify: true and removing certificate-authority-data from the kubeconfig file works.

Client Version

20

Kubernetes Version

1.28.6

Java Version

17

To Reproduce

Get a kubeconfig with a tls-server-name field different from the server field. This is the case with the kubeconfig files generated by Teleport. Run the KubeConfigFileClientExample.java:

cd examples/examples-release-20
mvn -X clean install exec:java -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample"

Expected behavior

The client respects the tls-server-name field and uses this hostname to verify the TLS certificate.

KubeConfig

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: REDACTED
    tls-server-name: REDACTED
  name: REDACTED
contexts:
- context:
    cluster: REDACTED
    extensions:
    - extension: sandbox
      name: teleport.kube.name
    user: REDACTED
  name: REDACTED
current-context: REDACTED
kind: Config
preferences: {}
users:
- name: REDACTED
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - kube
      - credentials
      - --kube-cluster=sandbox
      - --teleport-cluster=REDACTED
      - --proxy=REDACTED
      command: tsh
      env: null
      provideClusterInfo: false

Server (please complete the following information):

  • OS: Linux
  • Environment: system
  • Cloud: Azure/Teleport

Additional context
</issue_description>

Comments on the Issue (you are @copilot in this section)

@brendandburns Yeah, that's not currently supported in our TLS. We'd be happy to take a PR to add support.

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

@k8s-ci-robot k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. labels Nov 17, 2025
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Copilot
Once this PR has been reviewed and has the lgtm label, please ask for approval from brendandburns. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

1 similar comment
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Copilot
Once this PR has been reviewed and has the lgtm label, please ask for approval from brendandburns. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. labels Nov 17, 2025
@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Nov 17, 2025
Copilot AI changed the title [WIP] Fix client validation for tls-server-name in kubeconfig Support tls-server-name field from kubeconfig for SNI Nov 17, 2025
Copilot AI requested a review from brendandburns November 17, 2025 23:07
Copilot finished work on behalf of brendandburns November 17, 2025 23:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TLSServerName is not taken into account

3 participants